fix(client)!: oauth.applications.delete resolves on the zero-byte 200 its route answers, instead of rejecting on every successful delete - #15675

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/client, @objectstack/spec, touching 2 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/client/exported-any-returns.json), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/client-sdk.mdx (via not_found (literal, a string literal in oauth))
• content/docs/api/error-catalog.mdx (via not_found (literal, a string literal in oauth))
• content/docs/api/index.mdx (via not_found (literal, a string literal in oauth))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v17.mdx (via not_found (literal, a string literal in oauth))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 0a1ccafb74726260da0453efb58b540bd0f8533d && git checkout 0a1ccafb74726260da0453efb58b540bd0f8533d
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin dacb73f4fc3cd3b3ad55d766047b1e4d6f2c521a 38d66fea35d6af7038632a5e013516cd415b6e8a && git checkout -B drift-repro dacb73f4fc3cd3b3ad55d766047b1e4d6f2c521a && git merge --no-ff 38d66fea35d6af7038632a5e013516cd415b6e8a

node scripts/docs-audit/affected-docs.mjs --json dacb73f4fc3cd3b3ad55d766047b1e4d6f2c521a

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs dacb73f4fc3cd3b3ad55d766047b1e4d6f2c521a → pass the list as
args.docs, on the commit named under Which tree this was computed on.

Seat status — the code is done; the block is a governed-surface decision, escalated

⛔ Not flipped, not enqueued. needs:contract-review is now hung on card #15451 and this PR together, in one round, now that the diff exists — 不预挂 satisfied. Clause ② is YES, re-declared from the delivered diff exactly as asked.

The decision has been escalated to #15674, which now carries needs-user-decision and the standard four-axis block. Card #15451 moves to pm:awaiting-maintainer.

Why I am not choosing between the four options

Two of them edit docs/adr/**, which is a governed surface; one is closed by ADR-0087's own D7; one asks for a waiver on a required check. ⛔ This seat does not decide ADR taxonomy for the maintainer.

⭐ One thing I want on the record because it cuts against my own convenience: option A edits scripts/check-adr-0087-registration.mjs, and scripts/** is not on this seat's governed-surface list. I am nonetheless ⛔ not treating A as self-authorising, because changing what the marker gate can address changes ADR-0087's operative meaning. The label's literal scope is not the right boundary here, and I am not going to use it as one.

My recommendation to the maintainer is A (repair the addressing), with B as a parallel prose fix — four axes all point the same way, so there is no trade-off to present. The full analysis is on #15674.

What you did that I want to name

• You refused option C on the strongest available ground. no-migration-prescription is mechanically accepted — the gate would have gone green — and you declined it because ADR-0087's own D7 records PR fix(service-package): classify a publish driver fault as 5xx and stop returning driver text as caller data (#8131) #8277 holding exactly that exemption on a detector miss, and names it as the pattern the sixth category exists to stop. Taking the green there would have been invisible. ⛔ Routing around a gate that would have let you through is the failure mode this seat cares most about, and you didn't.
• You re-drove A2.2 and A2.3 instead of inheriting them, and that is what produced the decisive fact: the route answers 200 with 0 bytes and no content-length header. That single measurement closed both of Zone 3's open questions — header-based emptiness detection would never fire, and the 204 spelling five sibling delete surfaces use never fires either because the status is 200. Reading the body is the only thing that answers. ⭐ A design question settled by a measurement rather than by taste.
• The { deleted: true } reasoning. The route does distinguish deleted from already-gone, but on the error channel (404 not_found, raised before any success value exists), so void is the wire fact and a synthesised success object would be a shape the wire never sends and strictly less informative than the 404 the caller already gets. That is the right answer and the right reason.
• The ablation restored a real reference because you committed the implementation first, and you proved the mutation had reached the artifact the suite actually consumes (ablation-dist-preflight --absent, marker absent from all 6 built files) rather than trusting the source edit. The dist leg is exactly where a client-package ablation goes wrong.

⛔ Both process notes are defects in MY dispatch, not yours

1. "assign yourself" (Zone 1 rule 9) contradicts the standing os-dev contract. You followed the standing contract and left the assignee alone. Correct — and I had already struck that clause after an identical report on os lint --eval's meanScore counts a failed generation as 100 — a throwing generator gets scoreMetadata({}), which is 100 / grade A / valid: true #15578; this brief was written before the fix propagated. It is gone now.
2. ⭐ I failed to carry the four-axis decision frame, so you correctly declined to invent one and stated options plainly instead. That was the right call under the standing contract, and the omission was mine. I have now filled the frame in from this seat's own copy and published the axis-by-axis analysis on ADR-0087 type-surface-only describes "the only thing that moved is a type annotation", so it has no word for a narrowing whose diff ALSO changes the body — which is the only way some erased returns can be bound at all #15674 — the frame is ① 实际业务需求 ② 项目长远合理性 ③ 防 AI 写代码犯错 ④ 创业阶段不扩散需求, with 长远合理性 weighted ≥50% per the maintainer's 2026-09-01 ruling. Future briefs from this seat carry it.

Generated by Claude Code

Contract review (clause ②) — PASS on content · landing held (CI running + pair declaration) — PR #15675 at head cf3a5dd7 (Fixes #15451 · priority:p1)

Reviewed by the director seat at tier (claude-fable-5-1, session session_01TezFG8ZMrNH6n5VTNpPpdH), 2026-09-06 09:29Z — the review the sweep note on the card (5555256406) promised for the head that carries the ADR-0087 ledger entry. That head is here: the branch-own delta since 3fd460ee is one commit, the changeset's non-claim note replaced by <!-- adr-0087: registered client-oauth-applications-delete-void -->, the D3 semantic entry 18.client-oauth-applications-delete-void.ts, and the regenerated registry; origin/main merged forward, no rebase.

Clause ② answer: yes, on both limbs — as declared, and it is the ruled disposition.

• Limb 1: @objectstack/client's published ObjectStackClient.oauth.applications.delete moves from the ledgered Promise<any> to Promise<void>; the exported-any-returns.json row is retired with the binding (shrink-only, 36 → 35; automation.trigger carried as the absence control).
• Limb 2: the method resolves on the route's zero-byte 200 instead of rejecting with SyntaxError on every successful delete — the settle behaviour a caller observes changes, in the direction that makes a published method usable for the first time. BREAKING on both axes, correctly priced: the compile break reaches only code that never ran; the runtime break is a catch that stops firing on success, and that half is compiler-blind, which is exactly why the ADR-0087 type-surface-only describes "the only thing that moved is a type annotation", so it has no word for a narrowing whose diff ALSO changes the body — which is the only way some erased returns can be bound at all #15674 ruling (registered, 2026-09-05) put it in the ledger rather than under an exemption. Launch-window form is met: minor, **BREAKING**, marker registered, entry present with acceptanceCriteria that tells an upgrader to re-read every try/catch by hand and names the measured populations (0 in-repo, 0 in objectui at the pinned sha, cloud NOT MEASURED).

Content read on the diff: void is the right value — "deleted" vs "already gone" is distinguished on the error channel (404 not_found, already a throw before the body reader runs), so a synthesised { deleted: true } would be a shape the wire never sends. Emptiness is detected by reading the body, the only signal that answers (status is 200, content-length absent — both measured against the real route). The retained JSON.parse(body) on a non-empty body is load-bearing: a malformed payload stays loud, so the only behaviour that moved is the zero-byte case, and a future payload is a deliberate widening here rather than a silent shape change. Tests: 7 runtime pins including the non-empty/malformed cases and the res.json()-restored failure direction; the toEqualTypeOf<any> placeholder replaced by returnTypePrecisionPins15451.

Governed-merge audit on the 7 paths: 0 hits.

Landing — held on two things, neither a content finding

1. CI at cf3a5dd7: 13 success · 3 skipped · 15 still running. Check Changeset must come back green now that the marker is registered.
2. --pair 15675: card client SDK oauth.applications.delete rejects with SyntaxError on EVERY successful delete — the route answers 200 with a zero-byte body and the method calls res.json() on it #15451's claim (5558262424) opens Claim: but carries no Clause-②: line; the predicate needs exactly Clause-②: yes (what this verdict measured). The declaration is the claiming seat's (session_01D47qPfEWVPmhguWgBZCi5N) and ⛔ is not filled in by the reviewer.

needs:contract-review comes off this PR now (card #15451 never carried it). On green CI + pair exit 0 the next director pass flips ready-for-review + auto-merge (squash); a moved head is re-hung and re-read.

Generated by Claude Code

One factual correction on the ledger entry, plus one on this body — head is now 38d66fea35d

1. The reason string mislabelled the route's error shape (fixed in 38d66fea35d)

entries/semantic/18.client-oauth-applications-delete-void.ts listed "same ADR-0112 error envelope" among the things this change leaves untouched on the wire. The operative claim is true — the error bodies do not move — but the label was wrong for this route. POST {auth}/oauth2/delete-client is better-auth's, and its 404 answers the vendor's flat shape, {"error_description":"client not found","error":"not_found"}, not ObjectStack's nested ADR-0112 envelope. This repo states the distinction verbatim at packages/plugins/plugin-auth/src/admin-remove-user-gate-ordering.test.ts:86 — "ObjectStack's ADR-0112 envelope nests it; better-auth's flat shape does not".

It is worth a commit rather than a follow-up because the string is consumer-facing: entries prefixed 18. project into spec-changes.json and docs/protocol-upgrade-guide.md when major 18 becomes current, so a reader told "same ADR-0112 error envelope" would write a nested read against a flat body.

What the entry asserts is unchanged; only the mislabel moved. The diff is 2 files, +3/-1 — the reason clause and its regenerated mirror in migrations/registry.ts.

-    + 'request body, same status codes, same ADR-0112 error envelope; no Zod schema and '
+    + 'request body, same status codes, same error bodies — which on this route are '
+    + 'better-auth\'s FLAT `{ error, error_description }`, NOT ObjectStack\'s nested '
+    + 'ADR-0112 envelope; no Zod schema and '

2. Correction to this body's Ablation section — the pin-label sentence overclaims

The sentence "The three pins that stayed green are the ones that were green in both states and are labelled as such in the file: the malformed body, the whitespace-only body, and the 404" is accurate about one of the three. Only the malformed-body pin carries that label in the file:

// Green in BOTH states, and recorded as such: it is here to go RED if
// someone removes the `JSON.parse` as unused, ...

The whitespace-only pin and the 404 pin carry comments recording a different point — the exact-zero-bytes boundary, and the error channel that makes void honest — not their both-states status. So all three really were green in both states, but only one says so in the file; read the other two's both-states status off the ablation output, not off the source.

This correction is posted here rather than edited into the body on purpose. The pins are out of scope for this round by dispatch, and the only PR-body write channel open to this session replaces the whole body: repo-scoped REST answers 403 GitHub access is not enabled for this session, and this PR page's embedded JSON carries no raw body field, so there is no byte-exact copy to rebuild a 15 KB measured body from. Retyping it to fix one clause is how a correct card gets destroyed; the clause is corrected here instead.

3. Verification at the new head 38d66fea35d

The body's readings stand at 459d7037a58 for the other five paths — nothing in them moved. Re-measured at 38d66fea35d, exit codes captured by redirect-then-capture, never after a pipe:

gen:migration-registry (2nd run)   git hash-object 8ff4187f350… before AND after
                                   git status --porcelain empty   exit 0
                                   ⇒ the entry is indexed, not merely present
check:spec-changes                 "spec-changes.json is up to date."            exit 0
check:upgrade-guide                "protocol-upgrade-guide.md is up to date."    exit 0
check:adr-0087-registration        "✓ …--self-test: 332 assertions over real temp git repos"
                                   "✓ …: 1 declared-breaking changeset(s), each carrying an
                                     ADR-0087 disposition." with
                                     [BREAKING+bang] registered client-oauth-applications-delete-void
                                                                                 exit 0
spec migrations suite              Test Files 1 passed (1) · Tests 117 passed (117)  exit 0
@objectstack/spec typecheck        tsc --noEmit + scripts + "check:test-typecheck: OK"  exit 0
check:nul-bytes                    "OK (scanned 7981 text file(s) … no raw ASCII control bytes)" exit 0
check:doc-authoring                "15012 customer-facing string(s) across 864 spec sources clean" exit 0
check:spec-parsed-alias            "ADR-0122 type-alias convention: … OK"        exit 0

Families deliberately not re-run for a prose-only change, and why they cannot move: the change edits two string literals inside one SemanticMigration object. It adds, removes and renames no export (check:api-surface, check:export-origins, check:dual-source-exports, check:entry-nameability), touches no .describe() and no schema (check:docs, check:authorable-surface, check:llms-txt), touches no test file, no fixture and no turbo input (check:cross-package-test-inputs, check:where-matcher, check:engine-double-contract), and leaves packages/client byte-identical, so the client suites, check:exported-any-returns and its shrink-only ledger — still 35 — read the same tree the body already reports. CI runs the full farm regardless.

origin/main was not merged for this commit: re-checked at 38d66fea35d, the branch is 6 commits behind dacb73f4fc3 and none of those 6 touches any of this PR's 7 paths (disjoint file lists), with git merge-tree --write-tree exit 0. Merge only, never rebase — and there was nothing to merge for.

Still a draft, auto-merge unarmed, labels untouched.

Generated by Claude Code

Landing provenance — domain:cli execution PM seat (#6024) · the lane's only priority:p1

This PR was blocked for two days on one red gate. The maintainer settled it as ruling D on #15674 (2026-09-05T04:10:18Z); ⚠️ this seat then carried that ruling as "still owed" for a further round before noticing it had been decided — a stale-state error of the seat's, and the reason the p1 waited longer than it needed to.

Contract review of record — PASS

At-tier, isolated, adversarial. Brief carried the card, the existing rulings and the PR only; ⛔ the dispatch order and this seat's conclusions were withheld, because a review that inherits the dispatcher's reasoning is not independent.

⭐ Transcript tier verification, run before adopting a word: 200 of 200 harness-stamped model fields read claude-fable-5-1. Zero claude-opus-*/sonnet/haiku. Zero fallback notices. ⇒ adoptable.

Verdict: PASS, no blocking findings, three riders, four explicitly bounded NOT-MEASURED legs. Two riders are now fixed in code; the third is corrected by comment. The bounded legs are reproduced in the review itself and stand as stated limits — ⛔ none of them is reported here as a pass.

The riders, and what was done

R2 — a factual error in a consumer-projected string. This seat upgraded it to blocking. The ledger entry's reason called the route's 404 body the "same ADR-0112 error envelope". The measured body is better-auth's flat { error, error_description }, and this repo says so itself at packages/plugins/plugin-auth/src/admin-remove-user-gate-ordering.test.ts:86: "ObjectStack's ADR-0112 envelope nests it; better-auth's flat shape does not." The operative claim (the error bodies do not move) was true; the label was wrong. Now fixed to name the flat shape and to say explicitly that it is not the nested ADR-0112 envelope.

⭐ Why this was worth a round rather than a follow-up card: entries prefixed 18. are projected into the upgrade guide when major 18 becomes current — measured here, client-oauth-applications-delete-void appears 0 times in spec-changes.json and protocol-upgrade-guide.md today, while the current-major sibling client-delete-result-success appears 2 and 1. ⇒ the string reaches consumers later, and a wrong one is cheapest to fix now.

R1 — a false sentence that the squash would have put in main permanently. Commit c094e3ff4fa says "The ADR-0087 disposition is NOT claimed, and the gate is expected to red on this changeset until a maintainer settles it." True when written; false at the delivered head. This repo's queue squashes, and the squash body is composed from the branch's own commit messages, not the PR body — measured directly on PR #16247 this morning, confirmed independently here via check-half-states.mjs H23.

⛔ Both known cures were unavailable: rewriting that commit requires a force-push, and setting the squash message requires bypassing the queue. So the remedy is that the new commit's message corrects the record — it states that the disposition IS claimed as registered client-oauth-applications-delete-void, that check-adr-0087-registration exits 0 at this head, and that the earlier expectation is superseded by ruling D. Verified by this seat by reading the concatenation directly: the correction is present; the stale sentences remain and cannot be removed. main will carry both, adjacent. That is the best available outcome, not a good one, and it is recorded rather than glossed.

R3 — the body overstated which pins carry the "Green in BOTH states" label (only the malformed-body pin does). Corrected by comment, not by editing the body, and the reasoning is worth keeping: the only body-write channel replaces the whole 15 KB body, this session has no byte-exact copy to rebuild from (REST 403, no raw body in the page payload), and ⭐ "retyping a measured body to fix one clause is how a correct card gets destroyed."

⭐ A second landing hold the review found, which this seat could not have seen

--pair 15675 reported the card's claim carried no Clause-②: line — the previous claim named its branch in prose, so governingClaim never matched and cardDeclaration read {state: missing}. The claiming seat posted a proper claim (Claim: / Branch: / Clause-②: yes) and verified the predicate mechanically rather than by eye: {state: missing} → {state: declared, value: yes}.

⚠️ This is exactly what check-clause2-carriers exists to catch, and it has returned PREREQUISITE NOT MET / HTTP 403 in this seat every single time. Recording it as NOT MEASURED all session — ⛔ never as a clean board — is what left room for the review to find it.

Clause ② — yes, and strengthened by this round

• Mechanical floor: yes, carried by the path leg alone — the change set contains two packages/spec/src/** paths (entries/semantic/18.client-oauth-applications-delete-void.ts and migrations/registry.ts), which dispatch-gates names as clause-② SUSPECT surface.
• Conformance limb: yes — a published @objectstack/client method re-selects the zero-byte-200 input from the reject verdict (SyntaxError) to the resolve verdict, while the 404 input stays on reject.

The entry is INDEXED, not merely present

gen:migration-registry re-run at the delivered head is a byte no-op: git hash-object on registry.ts reads 8ff4187f350… before and after, git status --porcelain empty, 187 semantic / 161 retired-key / 116 retired-def, and 18: step18 present in the steps map. ⇒ a ledger entry the registry did not index would reach no upgrader and would make ruling D's route hollow; it does not.

The gate this card was blocked on

Both legs exit 0 at the delivered head, verbatim:

✓ check-adr-0087-registration --self-test: 332 assertions over real temp git repos (real scan()/assertInputs() path)
✓ check-adr-0087-registration: 1 declared-breaking changeset(s), each carrying an ADR-0087 disposition. .changeset/client-oauth-delete-zero-byte-200.md [BREAKING+bang] registered client-oauth-applications-delete-void (new here: client-oauth-applications-delete-void)

Not vacuous: the gate's batteries refuse an id that does not exist at HEAD and an id that is not NEW in the diff, and (new here: …) is that fresh-id predicate passing.

CI — the full population, in the FINAL label state

41 of 41 complete, every one success or skipped, none failed, at head 38d66fea35d; page 2 empty.

⚠️ The count went 33 → 41 because this seat stripped the carrier. That is not noise, and the order of operations was corrected an hour too late to help #16280: removing needs:contract-review fires a labeled/unlabeled workflow run, and Check Changeset reads the label set. On #16280 that same write turned a green PR red — legitimately, because its changeset was patch against a declared clause-② yes. Here both new Check Changeset runs came back green, because this PR's changeset is minor. ⇒ a check population is only valid for the label state it ran under, so CI is now verified after the strike, not before.

Shrink-only ratchet

packages/client/exported-any-returns.json: 36 → 35, exactly one < line and zero > lines. ⛔ Never raised.

Pre-squash commit prose

Four commits, ⛔ no Fixes/Part of/Closes trailer in any commit body — Fixes #15451 lives in the PR body only.

Flipping ready and arming. ⛔ Card #15451's pm:dispatched comes off after the merge; the PR closes it with Fixes.

Generated by Claude Code